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The current document contains a brief description of a 
system for Reasoning about Actions and Change called 
PAL (Pertinence Action Language) which makes use of 
several reasoning properties extracted from a Temporal 
Expert Systems tool called Medtool. 

General Information 

The PAL system (standing for Pertinence Action Lan- 
guage) is an interpreter of a causal language for describ- 
ing action domains and it has been proved in PCs under 
Linux and Sun workstations under SunOS. It is written 
in C (using GNU's compiler gcc 2.7.2.1) and sized in 
150K of source code, distributed in around 6500 lines. 
The executable is sized in 65/80K (depending on the 
platform). The programming effort can be estimated 
in about 1 man/years. 

Description of the System 

The purpose of PAL is to show the effects of usi ng the 



concept of Pert inence (formally introduced in (Otero 
fc Cabalar 1999|)) in problems of Reasoning about Ac- 



tions and Change, and to help in establishing seman- 
tic features about the logical formalization of this con- 
cept. The features of Pertinence have been extracted 
from a practical tool for Temporal Expert Systems 



(mainly for the medical domain(Barreiro et al. 1993; 


Otero et al. 1988; 


Heras & Otero 1995)) called Med- 


tool (Medtool 1995 


) which uses a formalism very close 



to the current one used in PAL. 

The tool is initially intended for solving temporal pro- 
jection problems, being planning problems reduced to 
small sized ones, but we expect to use it as a starting 
point for future efficiency improvements. 

Applying the System 

The system can be tested in two different ways, both 
available in the web page 

\protect\vrule widthOpt\protect\href {http : //www 

The two options are: 
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For an easy to use way, a simple web-based interface 
(PalWeb) has been implemented. It is enough with 
writing a domain description in the input box (or 
just selecting one of the preinstalled examples) and 
pressing the Process button to see the results. 

2. The other option is downloading the source code (file 
pall . 2 . tar . gz) and compiling it in a local machine. 
To this aim, follow the next steps: 

gunzip pall . 2 . tar . gz 
tar -xvf pall. 2. tar 
cd pall. 2 
make 

Finally, for testing the system, try any of the files in 
the examples directory: 

pal < examples/yale .pal 

We may also use the executable in the following way: 
pal examples/yale . pal 

so that standard input remains open to accept new 
queries or new action executions, providing a rudi- 
mentary interpreter. 

Methodology 

No general methodology has been developed by now, al- 
though due to the closeness to Medtool, many method- 
ological aspects can be directly inherited from practical 
experience in Medtool expert systems design. 

Specifics 

The use of logic is the main feature of PAL with respect 
to previous work done on Medtool expert systems de- 
sign. The purpose of PAL is to help in the logical for- 
malization for these practical systems so that new for- 
malism features can be incorporated or new tasks like 
explanation or planning can be done in a coherent way. 

As an action formalism, the main features of PAL 
. dc .^jj.udc . es/ ai\string~ cabalar /palMhttp : //www. dc . f i .udc . e 

1. It is narrative-based. Each model of a PAL theory 
has the shape of a finite sequence of situations. 



2. It is a causal formalism. Rules describing the domain 
behavior are causal rules. Pertinence acts in a simi- 
lar way to Lin's Caused predicate or to occlusi on, al- 
though there are fundamental differences (see ( Otero 



& Cabalar 199E)), especially on how rule conditions 
are interpreted. 

3. It allows concurrent actions. 

4. Actions and fluents are functional, though limited to 
finite domains and codomains. Arithmetic expres- 
sions relating actions and fluents are allowed. 

5. It allows both "real" execution and hypothetical rea- 
soning. There exists a real narrative which can be 
updated in an execution trace and whose (current 
and past) results can be consulted at any time. Hy- 
pothetical reasoning allows to test the results of an 
hypothetical execution, or to find plans that satisfy 
a given expression for a future situation. 

Each high level domain description is trans- 
lated into a set of ground rules using a prepo- 
sitional representation with two kinds of atoms: 
holds(Q, value, situation) and pertinent(Q , situation) 
(being Q a fluent or an action) . The system is intended 
for testing different semantics for these ground rules. To 
this aim, the rules behavior has been implemented in a 
separated module so that it can be easily changed. The 
first approach we have done is a version based on Well 
Founded Semantics, since it is the closest one to the 
way in which the practical tool currently works. This 
well founded version interprets the set of rules as an 
objective logic program, leaving default negation just 
for minimizing pertinent atoms. The iterative algo- 
rithm for computing the well founded model has been 
specialized so that pertinence minimization and inertia 
axioms are, in fact, executed implicitly. 

A second option that will be soon available is us- 
ing as "semantics" the inference mechanism of Medtool 
(which was already implemented in a C library known 
as Medtool-Connection). Of course, this would be an 
operational or procedural solution, but it is useful for 
comparing the practical tool results with the different 
logic-based versions. We also expect to incorporate a 
future Stable Models version (calling to smodels) and 
a Completion based version (using some SAT prover, 
following a similar technique to CCALC). 

The work could influence both areas of Reasoning 
about Actions and Temporal Expert Systems. The 
interest for the former could be theoretical (the in- 
troduction of pertinence in action domains) but also 
practical, since PAL formalization could eventually al- 
low studying Medtool expert systems as action the- 
ories. The interest for Temporal Expert Systems is 
that PAL provides an underlying logical formaliza- 
tion. Other less related areas could also be influ- 
enced. For instance, a strong relationship between 
Medtool practical formalism and Systems Theory for- 
malizations like DEVS (Discrete Events Systems Spec- 
ification) has been established ((Otero et al. I994|; 



the relation between the use of the real narrative done 
in PAL and approaches based on Temporal Deductive 
Databases. 

Users and Useability 

In order to use the high level language, the user does 
not need to be an expert in logic, although some no- 
tions about pertinence and logic-based systems is rec- 
ommendable. The basic syntax is quite direct, follow- 
ing the style of Medtool formalism, on which PAL is 
inspired. In fact, Medtool formalism is currently be- 
ing used by the experts (mainly physicians), so that 
they directly develop the expert systems, under some 
minimal assistance. However, in order to use PAL as a 
comparison tool for different semantic implementations, 
a deep knowledge about Nonmonotonic Reasoning and 
Logic Programming semantics will be required. 

As an example of flexibility, although it is not one of 
the initial purposes, PAL can also be indirectly used as 
a Logic Programming tool under Well Founded seman- 
tics. An example which includes the transformation 
steps to this aim can be found in PAL distribution (file 
wf .pal). 

The PAL system is currently under continuous devel- 
opment and has only been used by our research group 
until now. However, Medtool formalism, on which PAL 
is inspired, has been used for constructing several rea l 
Expert Systems (Barrciro et al. 1993j ; ptcro et al. 1988j ; 
Heras & Otero 1995), but also in the Financial domain. 



Evaluating the System 
Benchmarks 

Due to the premature stage of PAL, little comparative 
evaluation work has been done yet. The kind of proper- 
ties usually evaluated in actions formalizations are more 
theoretical, especially related to flexibility and elabo- 
ration tolerance, than practical, like memory usage or 
response time, although several approaches are already 
obtaining successful results for these last parameters. 
As explained in the description section, many usual ac- 
tion topics like, for instance, qualifications, defeasible 
rules or delayed effects, are not covered yet by PAL, 
although their introduction is a subject of current re- 
search. However, we think that the current version pro- 
vides enough expressivity for a practical use, properly 
dealing, for instance, with the frame and ramification 
problems (as shown by standard examples included in 
files yale.pal and suitcase .pal). 

Unfortunately, there are not too many benchmarks 
for testing action approaches yet. As an exception, we 
could mention the recent initiative of the Logic Mod- 
elling Workshop^, whose examples will be studied under 
PAL formalization. 

As for PAL time performance, we could mention that 
the system works acceptably well for temporal projec- 
tion problems. For instance, the execution of 5 transi- 



Otero et al. 1996)). Finally, we are also studying 
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tions for the domain example counter .pal, which con- 
tains a causal chain of 1000 fluents, is performed in 0.85 
seconds^. Also, some small planning problems can be 
performed in an reasonable way. For instance, it takes 
0.42 seconds for finding all the 781 ways for opening 
Lin's suitcase in 5 situations (allowing concurrent ac- 
tions and no execution of any action). Planning may 
become excessively hard, since it is attached in a naive 
way, generating all the possible combinations of actions 
and allowing concurrent execution. A nonconcurrcnt 
actions option has been added for better planning per- 
formance in most usual domains. Thus, for instance, a 
solution of 11 situations long for the missionaries and 
cannibals problem is found in 0.13 seconds, and the 4 
solutions for that length are obtained in 0.7 seconds. 

With respect to user-friendliness, the main advan- 
tage is the comfortability of domain descriptions involv- 
ing numerical variables (limited to finite and discrete 
domains). For instance, the missionaries and canni- 
bals problem can be described using 9 high level rules. 
With respect to applying the system, the current ver- 
sion is mainly batch-oriented, although it can be used 
as a rudimentary interpreter by entering sentences from 
standard input. We plan to extend this capability to a 
real interpreter interface. 

Comparison 

As many action approaches, the PAL system can com- 
pete with planning systems, particularly in the expres- 
sivity of their representational formalism. However, no 
serious comparison to usual planning benchmarks has 
been established yet. 

Problem Size 

Temporal projection domains can be reasonably han- 
dled for thousands of fluents. Planning problems, how- 
ever, are quite limited yet, specially when dealing with 
a small/medium number of situations and concurrent 
execution of actions. 

The system must be considered as a prototype, but 
several efficiency improvements (goal-directed planning, 
taking benefit of particular structures in the rules, 
heuristics, etc) are currently under study and could al- 
low handling larger planning problems. 

An example: the blocks world 

In this last section, we include, as a piece of syntax 
example, a possible representation of the blocks world 
domain. We will not provide an exhaustive description 
of PAL syntax, but will emphasize instead those most 
relevant features of the formalism. A PAL domain de- 
scription consists of two parts: declarations and sen- 
tences. In the declarations part, we define the sets of 
fluents, actions and rules, using perhaps some auxil- 
iary definitions of constants and sets to this aim. For 
instance, we will declare the following sets: 

2 A11 times obtained in a 133MHz Pentium with 32M of 
RAM and under Linux Slackware 2.0.29. 



sets 

block = [1,4] ; 

location = block + {table}; 

Intuitively, these lines define the set of blocks as the 
integers from 1 to 4, and the set of locations as any 
block or the table. A set is usually defined as a group 
of elements embraced by { . . . } , like for instance the 
singleton set {table}. Elements in a set can be both 
symbol names (an identifier with a lower-case initial, 
like table) or integer numbers. An alternative way of 
defining a set is using the interval notation, so that 
[1,4] is equivalent to {1,2,3,4}. Set expressions can 
be constructed using binary operators + ,-,* standing 
for union, difference and intersection respectively. 

Actions and fluents are considered to be functions. 
Thus, an action or fluent definition consists of the de- 
scriptions of its domain and codomain using the stan- 
dard mathematical notation: 

f: setl x set2 x set3 -> set4 

Note that, although x is used here as an operator, 
it can also be used as an identifier, depending on the 
grammar context. As an example of functional action, 
we define: 

actions 

carry: block -> location; 

so that we carry a block to a unique location. Notice 
that, in this way, we implicitly specify that a block can- 
not be placed on two different locations, since the value 
of a function (i.e. each carry (B)) is unique. In the 
example, we will use the following fluents: 

fluents 

loc: block -> location; 
free: block -> {true, false}; 

When a fluent is boolean, we can simply ignore the 
codomain definition in the following way: 

free: block; 

In the same way, we could define actions or fluents 
without domain. Imagine an action for just marking a 
unique block: 

actions 

mark: -> block; 

or a fluent that points if we have made some mark: 

fluents 

markdone : -> {true , false} ; 

This last case can be further abbreviated as: 

fluents 
markdone ; 

In the declarations section we can also define vari- 
ables. In PAL, variables are identified by an upper-case 
initial, and vary on a given sort. They are used for 
defining rule schemata and for making complex queries. 
We will use the following two block variables: 



vars 

B,C : block; 

Finally, the declarations section would contain the 
set of rules describing the system behavior: 

rules 

loc(B) :=carry(B) ; 

not free(C) if carry (B)=C; 

free(B) if pert (carry (C) ) and prev(loc(C))=B; 
false if pert (carry (B) ) and not prev(free(B) ) ; 
false if carry(B)=C and not prev(f ree (C) ) ; 

Rules have a head of shape: 
<f luent> : =expr 

and an optional condition preceeded by the conditional 
operator if. In a rule head we allow the abbreviations: 

<f luent> 
not <fluent> 

standing for: 

<f luent> : =true 
<f luent> : =f alse 

respectively, and we allow constraint rules with a false 
head. 

Coming back to our example, the first rule says that 
whatever the block B we carry, its current location 
loc(B) will be the value given by the carry (B) ac- 
tion. The second rule asserts that a block C becomes 
not free when we carry some B on top of it. The third 
rule says that if carry (C) is pertinent, that is, we carry 
C without regarding to which location, and the previ- 
ous location of C was B then B becomes free. The fourth 
rule asserts that we cannot perform a carry (B) when 
B was not free, whereas the fifth one, avoids carrying B 
to a nonfree block C. 

The sentences part may contain declarations about 
the actual narrative or queries. The actual narrative is 
first specified by providing the initial situation: 

initially 

loc(B) :=table,f ree(B) ; 

This means that all the blocks are on the table and 
are free. Performing actions in the actual narrative can 
be done in the following way: 

do {carry(l) :=2;} 

This would carry block 1 on top of block 2. The 
output would be the following one: 

1) 

carry (1) :=2 
loc(l) :=2 
free (2) : =f alse 

The output shows only the pertinent facts, just point- 
ing out the performed action and its derived effects (all 
the rest has persisted) . We can perform several actions 
in a sequence: 

do {carry(l) :=table; carry(2) :=3; carry(l) :=2;> 



which would have as output: 
2) 

carry (1) :=table 
loc(l) :=table 
free (2) :=true 
3) 

carry (2) : =3 

loc(2) :=3 

f ree(3) :=f alse 

4) 

carry (1) :=2 
loc(l) :=2 
free (2) : =f alse 

Notice how performing actions is an incremental task: 
the execution of the sequence generates situations from 

2 to 4, since it was performed taking 1 as the initial 
situation (that is, the one we had obtained previously). 
We can reinitialize ("resume") the actual narrative by 
providing a new initially clause. Besides, actions can 
also be performed concurrently, or we can even perform 
no action: 

initially 

loc(B) :=table,free(B) ; 
do {carry(l) :=2,carry(3) :=4; carry(l):=3; ; } 

that is, we first simultaneously move 1 on top of 2 and 

3 on top of 4, in the next situation, we move 1 to 3, and 
finally we perform no action. The output would be: 

Resume 
1) 

carry(l) :=2 
carry (3) :=4 
loc(l) :=2 
loc(3) :=4 
free (2) : =f alse 
free (4) : =f alse 
2) 

carry(l) :=3 
loc(l) :=3 
free (2) : =true 
f ree(3) :=f alse 
3) 

Finally, we will briefly comment the other kind of 
sentences: queries. The simplest kind of query allows 
asking about the current state. For instance, we can 
check that block 2 is free and it is on table: 

query 

free (2) and loc(2)=table? 
yes 

Variables can be used in a similar way to Prolog 
queries. For instance, we can find all the blocks that 
are not free: 

query 

not free(B)? 



B=3 
B=4 

2 solutions 

The general shape of queries allows asking properties 
about an hypothetical future. Answers will have the 
shape of plans, that is, sequences of actions to be per- 
formed for satisfying the query. For making some tests, 
we will add the assumption of non-concurrency of ac- 
tions (otherwise, we should add a rule for specifying 
that there is not space for two blocks on top of a third 
block) . The non-concurrency assumption is specified in 
the declarations part, for instance, as: 

options 

not concurrent ; 

Non-concurrency also assumes that an (unique) ac- 
tion is mandatorily performed. Now, using the initial 
state: 

initially 

loc(B) :=table,free(B) ; 

we can try to make block 3 not free in the next situation: 

query 

true;not free(3) ? 

\noindent obtaining 4 possible answers: 

\begin{ verbat im} 
Resume 

Solution 1: 
1) 

carry (1) :=3 
loc(l) :=3 
free (3) :=f alse 

Solution 2: 
1) 

carry (2) :=3 
loc(2) :=3 
free (3) : =f alse 

Solution 3: 
1) 

carry (3) :=3 
loc(3) :=3 
free (3) :=f alse 

Solution 4: 
1) 

carry (4) :=3 
loc(4) :=3 
free (3) :=f alse 

4 solutions 

Notice that in the current (present) situation we do 
not require anything and we use the true expression. 



When this happens, we can abbreviate it as an empty 
expression like in: 

query ; ; ; not free (3)? 

that would look for the ways of getting block 3 not free 
after 3 steps (this generates 1072 solutions!). We can 
fix the number of solutions we wish by another option: 

options 

solutions=l ; 

It is also possible to repeat the same expression a 
number of times along several situations. For instance, 
we can ask the queries: 

query 

. . .{3} not free(3) ? 

free(l) ...{3} not free(3)? 

so that the first one replaces our immediately previous 
example, and the second one tries to find ways of occu- 
pying block 3 in 3 steps but maintaining block 1 free. 
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